Execution of a secured environment initialization instruction on a point-to-point interconnect system

ABSTRACT

Methods and apparatus for initiating secure operations in a microprocessor system are described. In one embodiment, a system includes a processor to execute a secured enter instruction, and a chipset to cause the system to enter a quiescent state during execution of the secured enter instruction.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.11/442,230, entitled “EXECUTION OF A SECURED ENVIRONMENT INITIALIZATIONINSTRUCTION ON A POINT-TO-POINT INTERCONNECT SYSTEM” filed on May 26,2006.

FIELD

The present invention relates generally to microprocessor systems, andmore specifically to microprocessor systems that may operate in atrusted or secured environment.

BACKGROUND

The increasing number of financial and personal transactions beingperformed on local or remote microcomputers has given impetus for theestablishment of “trusted” or “secured” microprocessor environments. Theproblem these environments try to solve is that of loss of privacy, ordata being corrupted or abused. Users do not want their private datamade public. They also do not want their data altered or used ininappropriate transactions. Examples of these include unintentionalrelease of medical records or electronic theft of funds from an on-linebank or other depository. Similarly, content providers seek to protectdigital content (for example, music, other audio, video, or other typesof data in general) from being copied without authorization.

Existing trusted systems may utilize a complete closed set of trustedsoftware. This method is relatively simple to implement, but has thedisadvantage of not allowing the simultaneous use of common,commercially available operating system and application software. Thisdisadvantage limits the acceptance of such a trusted system.

Other approaches require systems to have their processors connected toeach other through a bus.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 is a diagram of an exemplary software environment executing in amicroprocessor system.

FIG. 2 is a diagram of certain exemplary trusted or secured softwaremodules and exemplary system environment, according to one embodiment ofthe present invention.

FIG. 3 is a diagram of an exemplary trusted or secured softwareenvironment, according to one embodiment of the present invention.

FIG. 4 is a flowchart of software and other process blocks, according toa method embodiment of the present invention.

DETAILED DESCRIPTION

The following description describes techniques for initiating a trustedor secured environment in a microprocessor system. In the followingdescription, numerous specific details such as logic implementations,software module allocation, encryption techniques, bus signalingtechniques, and details of operation may be set forth in order toprovide a more thorough understanding of the present invention. It willbe appreciated, however, by one skilled in the art that the inventionmay be practiced without such specific details. In other instances,control structures, gate level circuits and full software instructionsequences have not been shown in detail in order not to obscure theinvention. Those of ordinary skill in the art, with the includeddescriptions, will be able to implement appropriate functionalitywithout undue experimentation. The invention is disclosed in the form ofa microprocessor system. However, the invention may be practiced inother forms, such as in a digital signal processor, a minicomputer, or amainframe computer.

Referring now to FIG. 1, a diagram of an exemplary software environmentexecuting in a microprocessor system is shown. The software shown inFIG. 1 is not trusted (untrusted). When operating in a high privilegelevel, the size and constant updating of the operating system 150 makeit very difficult to perform any trust analysis in a timely manner. Muchof the operating system sits within privilege ring zero (0), the highestlevel of privilege. The applications 152, 154, and 156 have much reducedprivilege and typically reside within privilege ring three (3). Theexistence of the differing privilege rings and the separation of theoperating system 150 and applications 152, 154 and 156 into thesediffering privileged rings would appear to allow operating of thesoftware of FIG. 1 in a trusted mode, based on making a decision totrust the facilities provided by the operating system 150. However, inpractice making such a trust decision is often impractical. Factors thatcontribute to this problem include the size (number of lines of code) ofthe operating system 150, the fact that the operating system 150 may bethe recipient of numerous updates (new code modules and patches) and thefact that the operating system 150 may also contain code modules such asdevice drivers supplied by parties other than the operating systemdeveloper. Operating system 150 may be a common one such as Microsoft®Windows®, Linux, or Solaris®, or may be any other appropriate known orotherwise available operating system. The particular types or names ofapplications or operating systems run or running are not critical.

Referring now to FIG. 2, a diagram of certain exemplary trusted orsecured software modules and exemplary system environment 200 is shown,according to one embodiment of the present invention. In the FIG. 2embodiment, processor 202, processor 212, processor 222, and optionalother processors (not shown) are shown as separate hardware entities.Although FIG. 2 shows three processors, embodiments of the invention mayinclude any number of processors, including a single processor.

System 200 also includes chipset 240, which may include an input/output(I/O) controller or hub, along with any other system or other logic asdescribed below. Other embodiments may include other components insteador in addition to the components shown in FIG. 2, and the number ofprocessors or other components may differ, as may their arrangement withrespect to each other.

Processors 202, 212, and 222 may include one or more execution cores,such as cores 203, 205, 213, 215, 223, and 225. In some embodiments theprocessors or cores may be replaced by separate hardware executionthreads running on one or more physical processors or cores. Thesethreads possess many of the attributes of additional physicalprocessors. In order to have a generic expression to discuss using anymixture of multiple physical processors and multiple threads uponprocessors, the expression “logical processor” may be used to describeeither a physical processor or a thread operating in one or morephysical processors. Thus, one single-threaded processor may beconsidered a logical processor, and multi-threaded or multi-coreprocessors may be considered multiple logical processors.

Processors 202, 212, and 222 may also include “un-core” logic, such asun-core logic 201, 211, and 221, where “un-core” logic is logic that isseparate from any of the execution cores. Un-core logic may includeregisters or any other storage locations, such as registers 207, 217,and 227, which may be used to store information regarding the processoron which is resides. Such registers or storage locations may beprogrammable or hard-coded, and such information may include the numberof cores and/or logical processors included in the correspondingprocessor. Registers 207, 217, and 227 may be standard global memorymapped registers that are updated during power-on reset.

Processors 202, 212, and 222 may also contain certain special circuitsor logic elements to support secure or trusted operations. For example,processor 202 may contain secure enter (SENTER) logic 204 to support theexecution of special SENTER instructions that may initiate trustedoperations. Processor 202 may also contain interconnection message logic206 to support special interconnection messages between processors andother components in support of special SENTER operations. The use ofspecial interconnection messages may increase the security ortrustability of the system for several reasons. Circuit elements such asprocessors 202, 212, and 222 or chipset 240 may only issue or respond tosuch messages if they contain the appropriate logic elements ofembodiments of the present disclosure. Therefore successful exchange ofthe special interconnection messages may help ensure proper systemconfiguration. Special interconnection messages may also permitactivities that should normally be prohibited, such as resetting aplatform configuration register 278. The ability of potentially hostileuntrusted code to spy on certain interconnection transactions may becurtailed by allowing special interconnection messages to be issued onlyin response to special security instructions. SENTER logic 204,interconnection message logic 206, and any other logic used inembodiments of the invention may be implemented using any knownapproach, including logic circuitry, microcode, and firmware.

Additionally, processor 202 may contain secure memory 208 to supportsecure initialization operations. In one embodiment secure memory 208may be an internal cache of processor 202, perhaps operating in aspecial mode. In alternate embodiments secure memory 208 may be specialmemory. Other processors such as processor 212 and processor 222 mayalso include SENTER logic 214, 224, bus message logic 216, 226, andsecure memory 218, 228.

A “chipset” may be defined as a group of circuits and logic that supportmemory and/or I/O operations for a connected processor or processors.Individual elements of a chipset may be grouped together on a singlechip, a pair of chips, or dispersed among multiple chips, includingprocessors. In the FIG. 2 embodiment, chipset 240 may include circuitryand logic to support I/O operations for processors 202, 212, and 222,while each processor includes circuitry and logic to support memoryoperations. Alternatively, chipset 240 may also include circuitry andlogic to support memory operations for processors 202, 212, and 222. Thefunctions of chipset 240 may be allocated among one or more physicaldevices in alternate embodiments.

Chipset 240 may additionally include its own interconnection messagelogic 242 to support special interconnection messages on PTP fabric 230in support of special SENTER operations. Some of these specialinterconnection messages may include transferring the contents of a keyregister 244 to a processor 202, 212, or 222, permitting a processor toset or clear a special “QUIESCE” indicator 246 to cause chipset 240 toquiesce or de-quiese system 200 (as described below), or permitting aspecial “QUIESCED” flag 248 to be examined by a processor. An additionalfeature of bus message logic 242 may be to register the existence orparticipation of processors in system 200 in an “EXISTS” register 270.

Processors 202, 212, 222 may be connected with each other, to chipset240, and to any other components or agents through point-to-point (PTP)interconnection fabric 230. Processors 202, 212, and 222, and chipset240 may include interface units 209, 219, 229, and 239, respectively, toconnect to PTP fabric 230 and to transmit and receive messages to andfrom other each other and any other agents existing or participating insystem 200. Each of interface units 209, 219, 229, and 239 may includeany number of unidirectional and/or bidirectional ports forcommunication with any number of other components. Communications may bemade through PTP fabric 230 according to a layered point-to-pointinterconnection architecture, for example, where packets, includingsignals representing a messages and/or data, framed by any or all of alinking layer, a protocol layer, a routing layer, a transport layer, aphysical layer, and any other such layer, are transmitted from one agentto another agent (point-to-point). Accordingly, each of interface units209, 219, 229, and 239 may include circuitry or logic to generatesignals corresponding to each layer. The packets may also includeredundant or other information for the detection or correction oferrors.

Token 276, containing one or more platform configuration registers (PCR)278, 279 may be connected to chipset 230. In one embodiment, token 276may contain special security features, and in one embodiment may includethe trusted platform module (TPM) 281 disclosed in the Trusted ComputingPlatform Alliance (TCPA) Main Specification, version 1.1 a, 1 Dec. 2001,issued by the TCPA (available at www.trustedpc.com).

Two software components identified in system environment 200 are aSecure Virtual Machine Monitor (SVMM) 282 module and a SecureInitialization Authenticated Code (SINIT-AC) 280 module. The SVMM 282module may be stored on a system disk or other mass storage, and movedor copied to other locations as necessary. In one embodiment, prior tobeginning the secure launch process SVMM 282 may be moved or copied toone or more memory pages in system 200. Following the secure enterprocess, a virtual machine environment may be created in which the SVMM282 may operate as the most privileged code within the system, and maybe used to permit or deny direct access to certain system resources bythe operating system or applications within the created virtualmachines.

Some of the actions required by the secure enter process may be beyondthe scope of simple hardware implementations, and may insteadadvantageously use a software module whose execution may be implicitlytrusted. In one embodiment, these actions may be performed by SecureInitialization (SINIT) code. One exemplary action may require thatvarious controls representing critical portions of the systemconfiguration be tested to ensure that the configuration supports thecorrect instantiation of the secure environment. A second exemplaryaction may be to calculate and register the SVMM 282 module's identityand transfer system control to it. Here “register” means placing a trustmeasurement of SVMM 282 into a register or other storage location, forexample into PCR 278 or into PCR 279. When this second action is taken,the trustworthiness of the SVMM 282 may be inspected by a potentialsystem user.

The SINIT code may be produced by the manufacturer of the processors orof the chipsets. For this reason, the SINIT code may be trusted to aidin the secure launch of chipset 240. In order to distribute the SINITcode, in one embodiment a well-known cryptographic hash is made of theentire SINIT code, producing a value known as a “digest”. One embodimentproduces a 160-bit value for the digest. The digest may then beencrypted by a private key, held in one embodiment by the manufacturerof the processor, to form a digital signature. When the SINIT code isbundled with the corresponding digital signature, the combination may bereferred to as SINIT authenticated code (SINIT-AC) 280. Copies of theSINIT-AC 280 may be later validated as discussed below.

The SINIT-AC 280 may be stored on system disk or other mass storage orin a fixed media, and moved or copied to other locations as necessary.In one embodiment, prior to beginning the secure launch process SINIT-AC280 may be moved or copied into one or more memory pages of system 200to form a memory-resident copy of SINIT-AC.

Any privileged software running on system 200, such as an operatingsystem, may initiate the secure launch process on a logical processor,which may then be referred to as the initiating logical processor (ILP).In the present example processor 202 is the ILP, although any of theprocessors on PTP fabric 230 could be the ILP. Neither memory-residentcopy of SINIT-AC 280 nor memory-resident copy of SVMM 282 may beconsidered trustworthy at this time.

The ILP (processor 202) executes a special instruction to initiate thesecure launch process. This special instruction may be referred to as asecured enter (SENTER) instruction, and may be supported by SENTER logic204. The SENTER instruction may first verify that every logicalprocessor in system 200 is registered in chipset 240, for example inEXISTS register 270. Each processor and other agent connected to PTPfabric 230 includes a register or other storage location, such asregisters 207, 217, and 227, to indicate the number of logicalprocessors that it includes. These registers are read to verify that thesystem topology is accurately represented in chipset 240.

After this verification, the SENTER instruction writes to QUIESCEindicator 246 to cause chipset 240 to quiesce system 200. Chipset 240begins a handshake sequence on PTP fabric 230 to cause all processorsand other agents on PTP fabric 230, except for one processor (thequiescent state master), to enter a quiescent state. In this embodiment,processor 202 is the quiescent state master as well as the ILP. Thequiescence sequence may include sending a “STOP_REQ” signal to eachnon-master processor to cause them to finish their event processing,drain their buffers, and return a “STOP_ACK” signal back to chipset 240to acknowledge their entry into a quiescent state. The quiescent stateis a state in which they execute no instructions and generate notransactions on PTP fabric 230. After chipset 240 receives a STOP_ACKsignal from every agent on behalf of every logical processor registeredin chipset 240, QUIESCED flag 248 may be set.

After the system is quiesced, the SENTER instruction may securelyexecute the security module(s) as described below. For this purpose, PTPfabric 230 is still functional and TPM 281 is still accessible to thequiescent state master. After the execution of the security module(s) iscomplete, the quiescent state master may clear QUIESCE indicator 246 tocause chipset 240 to bring system 200 out of the quiesced state.

To execute the security module(s), the ILP (processor 202) may firstmove both a copy of SINIT-AC 280 and key 284 into secure memory 208 forthe purpose of authenticating and subsequently executing the SINIT codeincluded in SINIT-AC 280. In one embodiment, this secure memory 208 maybe an internal cache of the ILP (processor 202), perhaps operating in aspecial mode. Key 284 represents the public key corresponding to theprivate key used to encrypt the digital signature included in theSINIT-AC 280 module, and is used to verify the digital signature andthereby authenticate the SINIT code. In one embodiment, key 284 mayalready be stored in the processor, perhaps as part of the SENTER logic204. In another embodiment, key 284 may be stored in a read-only keyregister 244 of chipset 240, which is read by the ILP. In yet anotherembodiment, either the processor or the chipset's key register 244 mayactually hold a cryptographic digest of key 284, where key 284 itself isincluded in the SINIT-AC 280 module. In this last embodiment, the ILPreads the digest from key register 244, calculates an equivalentcryptographic hash over the key 284 embedded in SINIT-AC 280, andcompares the two digests to ensure the supplied key 284 is indeedtrusted.

A copy of SINIT-AC and a copy of a public key may then exist withinsecure memory 208. The ILP may now validate the copy of SINIT-AC bydecrypting the digital signature included in the copy of the SINIT-ACusing the copy of a public key. This decryption produces an originalcopy of a cryptographic hash's digest. If a newly-calculated digestmatches this original digest then the copy of SINIT-AC and its includedSINIT code may be considered trustable.

The ILP may now register the unique identity of the SINIT-AC module bywriting the SINIT-AC module's cryptographic digest value to a platformconfiguration register 272 in the security token 276, as outlined below.The ILP's execution of its SENTER instruction may now terminate bytransferring execution control to the trusted copy of the SINIT codeheld within the ILP's secure memory 208. The trusted SINIT code may thenperform its system test and configuration actions and may register thememory-resident copy of SVMM, in accordance with the definition of“register” above.

Registration of the memory-resident copy of SVMM may be performed inseveral manners. In one embodiment, the SENTER instruction running onthe ILP writes the calculated digest of SINIT-AC into PCR 278 within thesecurity token 276. Subsequently, the trusted SINIT code may write thecalculated digest of the memory-resident SVMM to the same PCR 278 oranother PCR 279 within the security token 276. If the SVMM digest iswritten to the same PCR 278, the security token 276 hashes the originalcontents (SINIT digest) with the new value (SVMM digest) and writes theresult back into the PCR 278. In embodiments where the first(initializing) write to PCR 278 is limited to the SENTER instruction,the resulting digest may be used as a root of trust for the system.

Once the trusted SINIT code has completed its execution, and hasregistered the identity of the SVMM in a PCR, the SINIT code maytransfer ILP execution control to the SVMM. In a typical embodiment, thefirst SVMM instructions executed by the ILP may represent aself-initialization routine for the SVMM. System 200 may then beoperated in trusted mode, as outlined in the discussion of FIG. 3 below,under the supervision of the now-executing copy of SVMM. From this pointonwards, the overall system is operating in trusted mode as outlined inthe discussion of FIG. 3 below.

Referring now to FIG. 3, a diagram of an exemplary trusted or securedsoftware environment is shown, according to one embodiment of thepresent invention. In the FIG. 3 embodiment, trusted and untrustedsoftware may be loaded simultaneously and may execute simultaneously ona single computer system. A SVMM 350 selectively permits or preventsdirect access to hardware resources 380 from one or more untrustedoperating systems 340 and untrusted applications 310 through 330. Inthis context, “untrusted” does not necessarily mean that the operatingsystem or applications are deliberately misbehaving, but that the sizeand variety of interacting code makes it impractical to reliably assertthat the software is behaving as desired, and that there are no virusesor other foreign code interfering with its execution. In a typicalembodiment, the untrusted code might consist of the normal operatingsystem and applications found on today's personal computers.

SVMM 350 also selectively permits or prevents direct access to hardwareresources 380 from one or more trusted or secure kernels 360 and one ormore trusted applications 370. Such a trusted or secure kernel 360 andtrusted applications 370 may be limited in size and functionality to aidin the ability to perform trust analysis upon it. The trustedapplication 370 may be any software code, program, routine, or set ofroutines which is executable in a secure environment. Thus, the trustedapplication 370 may be a variety of applications, or code sequences, ormay be a relatively small application such as a Java applet.

Instructions or operations normally performed by operating system 340 orkernel 360 that could alter system resource protections or privilegesmay be trapped by SVMM 350, and selectively permitted, partiallypermitted, or rejected. As an example, in a typical embodiment,instructions that change the processor's page table that would normallybe performed by operating system 340 or kernel 360 would instead betrapped by SVMM 350, which would ensure that the request was notattempting to change page privileges outside the domain of its virtualmachine.

Referring now to FIG. 4, a flowchart of software and other processblocks is shown, according to an embodiment of the present invention inmethod 400.

In block 410 of method 400, a logical processor makes a copy of theSINIT-AC and SVMM modules available for access by a subsequent SENTERinstruction. In this example, an ILP loads the SINIT-AC and SVMM codefrom mass storage into physical memory. In alternative embodiments, anylogical processor may do so, not just the ILP. A processor becomes theILP by executing the SENTER instruction, as identified in block 412.

In block 420, the SENTER instruction verifies that every logicalprocessor in system 200 is registered in chipset 240, for example inEXISTS register 270. In block 422, the SENTER instruction writes toQUIESCE indicator 246 to cause chipset 240 to quiesce system 200. Inblock 424, chipset 240 sends “STOP_REQ” signals to each non-masterprocessor to cause them to finish their event processing, drain theirbuffers, and return a “STOP_ACK” signal back to chipset 240 toacknowledge their entry into a quiescent state. In block 426, QUIESCEDflag 248 is set to indicate that chipset 240 has received a STOP_ACKsignal from every agent on behalf of every logical processor registeredin chipset 240.

In block 430, the ILP moves the public key of the chipset and thememory-resident copy of SINIT-AC into its own secure memory for secureexecution. The ILP, in block 432, uses the key to validate thesecure-memory-resident copy of SINIT-AC, and then executes it. Theexecution of SINIT-AC may perform tests of the system configuration andthe SVMM copy, then registers the SVMM identity, and finally begins theexecution of SVMM in block 434. In block 436, the quiescent state masterclears QUIESCE indicator 246 to cause chipset 240 to bring system 200out of the quiesced state in block 438.

In the foregoing specification, the invention has been described withreference to specific exemplary embodiments thereof. It will, however,be evident that various modifications and changes may be made theretowithout departing from the broader spirit and scope of the invention asset forth in the appended claims. The specification and drawings are,accordingly, to be regarded in an illustrative rather than a restrictivesense.

What is claimed is:
 1. A system, comprising: a first processor toexecute a secured enter instruction; and a chipset to cause the systemto enter a quiescent state during execution of the secured enterinstruction.
 2. The system of claim 1, further comprising apoint-to-point fabric to couple the first processor to the chipset. 3.The system of claim 2, further comprising a second processor coupled tothe chipset by the point-to-point fabric, wherein the chipset is also tocause the second processor to enter the quiescent state during theexecution of the secured enter instruction.
 4. The system of claim 2,wherein the chipset is also to cause the system to enter the quiescentstate in which only the first processor and the chipset communicatethrough the point-to-point fabric.
 5. The system of claim 1, furthercomprising a trusted platform module, wherein the trusted platformmodule is accessible to the first processor during the quiescent state.6. The system of claim 1, wherein the first processor is also to executea secure initialization authenticated code module.
 7. The system ofclaim 1, wherein the first processor is also to execute a secure virtualmachine monitor module.
 8. The system of claim 1, wherein the chipsetincludes an indicator accessible to the first processor to cause thechipset to cause the system to enter the quiescent state.
 9. The systemof claim 3, wherein: the chipset includes: an indicator accessible tothe first processor to cause the chipset to cause the system to enterthe quiescent state; and a first storage location to indicate theidentity of each processor in the system; the second processor includesa second storage location to indicate that the second processor isconnected to the point-to-point fabric; and the first processor includeslogic to verify that the identity of the second processor is indicatedin the first storage location before accessing the indicator to causethe chipset to cause the system to enter the quiescent state.
 10. Amethod, comprising: starting to execute a secured enter instruction on afirst processor coupled to a chipset through a point-to-point fabric;causing the chipset to cause a second processor coupled to thepoint-to-point fabric to enter a quiescent state during the execution ofa secured enter instruction.
 11. The method of claim 10, furthercomprising the chipset maintaining a list of agents coupled to thepoint-to-point fabric.
 12. The method of claim 11, further comprisingreading a storage location in the second processor to identify thenumber of agents coupled to the point-to-point fabric through the secondprocessor.
 13. The method of claim 10, further comprising the firstprocessor accessing a trusted platform module during the quiescentstate.
 14. The method of claim 13, further comprising executing a secureinitialization authentication module.
 15. The method of claim 14,further comprising reading an indicator in the chipset to verify thatthe quiescent state has been entered before executing the secureinitialization authentication module.
 16. The method of claim 13,further comprising executing a secure virtual machine monitor module.17. The method of claim 16, further comprising reading an indicator inthe chipset to verify that the quiescent state has been entered beforeexecuting the secure virtual machine monitor module.
 18. The method ofclaim 10, further comprising causing the second processor to finish itsevent processing and drain its buffers before entering the quiescentstate.
 19. The method of claim 18, further comprising the secondprocessor sending a signal to the chipset to acknowledge its entry intothe quiescent state.
 20. A processor, comprising: secure enter logic toexecute a first instruction to invoke secure operation initialization;and interconnection messaging logic to cause a chipset to cause an agentcoupled to the chipset through a point-to-point fabric to enter aquiescent state.